「アカツキ流セキュリティ監査自動化　〜400 個以上の Google Cloud プロジェクト監査を自動化したノウハウを一挙公開〜」というセッションを視聴しました。#GoogleCloudDay

「Google Cloud Day: Digital ’22」とは2022年4月19日～21日の日程でオンライン開催されているGoogle Cloudの最新ソリューションのカンファレンスです。

基調講演、特別講演、ブレイクアウト セッション、ハンズオンなど多様なプログラムを通して、Google Cloud が支援する企業のデジタル トランスフォーメーション（DX）の実現と、新たなビジネス価値の創造について、経営的、技術的観点から深く学べる機会です。 引用元：Google Cloud Day: Digital ’22

ということで、いろんな分野のセッションが1セッション30分ほどで用意されており、いつでも短時間で気になるGoogle Cloudの最新情報を確認できるようになっています。 アーカイブ動画もこちらから確認できるので参加できなかった方もぜひこちらから気になるセッションを視聴してみてください。

セッション概要

今回視聴したのは「アカツキ流セキュリティ監査自動化　〜400 個以上の Google Cloud プロジェクト監査を自動化したノウハウを一挙公開〜」というセッションです。

本セッションはアカツキゲームスの駒井 祐人氏が、実際にアカツキゲームスで400 個以上ある Google Cloud プロジェクトのセキュリティ監査を自動化した事例を紹介してくれるセッションになっています。 Google Cloudでのセキュリティ監査にお悩みの方、これから始めていきたいと考えている方におすすめのセッションになっています。

初めに質問です

例えば、組織の中に数百個のGoogle Cloudプロジェクトがあります。

• 全プロジェクトの中でサービスアカウントキーが何個発行されていて、いつからローテーションされていないか把握できるか？
• 一般公開されてしまっているGoogle Storageバケットを検知できるか？
• 利用頻度の低いGoogle Cloudプロジェクトや利用頻度の低いCompute Engineを検知できるか？

本セッションではこれらの質問に対しての回答、すなわち「400個以上のGoogle Cloudプロジェクトのセキュリティ監査を自動化した事例」を順を追って説明するという形で話が進められていきます。

COVID-19の影響により世界が大きく変わったことでクラウド利用の加速とともに、セキュリティインシデントも１８８％加速したという報告があります。 クラウド上の機密データを公開したままにしている組織も３０％にあるという報告もあるようです。

クラウドは簡単に脆弱になってしまいます。 どのようなリスクが増加するのかというと、

• サービスアカウントキーの流出で、Google Cloudの不正操作が可能になっってしまった場合
  • 個人商法流出リスク
  • システム停止/破壊リスク
• 公開バケットが存在し、Google Storageに置かれたデータの読み書きが可能になってしまった場合
  • データが、マルウェアを仕込まれた状態で上書きされ、ダウンロードしたPCがマルウェア感染するリスク

このようなリスクにより金銭損失、顧客損失、業務停滞、従業員への影響といった不利益が発生してしまいます。

アカツキゲームスのクラウドセキュリティ全体像

ざっくりとセキュリティを二つの概念に分けます

• 予防：不正なアクセスが外から入ってこないような仕組み作りやその設定がきちんとされているかの監査をしたりする防御壁の部分
• 検出：実際に組織の中に不正なものが入ってしまったときに検知する仕組みの部分

今回はこの予防の部分について詳しく説明してくれています。

Security Command Center(SCC)

Security Command CenterとはGoogle Cloudのセキュリティ管理サービスのことです。 組織のアセットを一元管理し、組織のセキュリティ対策状況をこのサービス一つで可視化することができます。

驚異の予防という観点から、全公開されてしまっているFirewallルールを検知したりなどの機能があります。検知は国際ルールに則ったものになるので非常に便利です。 脅威検出の検知機能も付いており、マルウェアの挙動や不正アクセスの挙動、暗号資産のマイニングといった脅威をマネージドに検出することが可能です。

PremiumとStandard

Security Command CenterにはPremiumとStandardがあり、機能が変わってきます。

Premiumは有料ですが全機能を使えるのでセキュリティ対策がばっちり利用できます。
Standardは無料という大きなメリットがありますが、使えない機能があるデメリットもあります。

アカツキゲームズではPuremium版が発表される前にセキュリティ対策に取り組んだため、Standard版＋他のツールを組み合わせたセキュリティ対策に取り組んでいるようです。 本セッションでフォーカスされている予防の観点ではForsetiというOSSを使いPremiumと同等レベルのセキュリティ監査を実現しているようです。

Forseti Security

Forseti SecurityとはGoogle Cloudのセキュリティ監査用OSSです。

• SCC Standardでは足りない監査を補うことができる
• 独自のカスタムルールを実装可能
• Security Command Centerと統合が可能（SCCのUIで組織の違反内容を一元管理が可能）

Forseti SecurityはOSSなので監視サーバーを運用する必要があります。 Forseti自身はCompute EngineとCloud SQLで動かし、サーバーが組織全体のアセットをチェックしセキュリティ監査のルールにのっとって違反内容を検知します。 ここで検知した違反内容をSCCに送ることで、SCCのUI上でこの違反項目を一元管理することが可能です。

1日1回違反項目が検知されると担当者に通知を送る仕組みもあるのでリアルタイムな違反の検知が可能です。 さらに実行時以外はサーバーを停止してコスト最適化が図れるようになっています。

上記はForsetiで検知している一例です。

IAMでは100日以内にローテーションされていないサービスアカウントキーを検知してくれます。 これは、セッションの一番最初の問いである

• 全プロジェクトの中でサービスアカウントキーが何個発行されていて、いつからローテーションされていないか把握できるか？

に対する回答になります。 Forseti を利用することで組織全体のサービスアカウントキーの発行数とローテーション状況の把握ができます。

また2つ目の問いの

• 一般公開されてしまっているGoogle Storageバケットを検知できるか？

に対する回答が、Cloud Storageの項目に書かれていることが分かります。 Forseti を利用することでCloud Storageの公開設定を組織一括で検知することが可能です。

SCC Standard＋Forseti Securityを利用することで実現できること

SCC StandardとForseti Securityを利用することで下記のようなことが実現できます。

• 400個以上のGoogle Cloudプロジェクトに対して社内セキュリティポリシーに沿った監査の自動化が可能になった
• Forsetiのサーバー費用は月4万円程度

ただ、Forsetiを利用する際にはいくつか注意点があると駒井氏は述べています。 メンテナンスに関しての不安要素があるため、OSSに細かい修正を加えたTerraform moduleを公開しているようです。 試してみたい方はこちらを利用してみてもいいかもしれないですね。

どのサービスを利用するのか？

Google Cloudでこれからセキュリティ対策をしようという組織は、Security Command CenterのPremiumをまずは見てみることが良いかもしれません。 こちらを採用するかどうかを検討したうえで、コストやカスタマイズ性を重視したい場合に本セッションで紹介されたような他のツールを組み合わせていくことを考えていくというのが、基本になるかと思います。

Recommender

Recommenderとはいわゆる推奨事項のことです。 これをうまく利用することで組織の中で放置されてしまっているリソースを確認することができます。

利用頻度が低いプロジェクトは推奨事項があっても検知しようがないため、組織一括でAPIを使って検知をするという仕組みを整えています。 運用としてはシンプルで、

• Cloud Asset Inventoryを利用し、組織全体のアセットを一括取得。
• アセットに推奨事項が存在するかチェックする

というような仕組みで動いています。

実現可能なこと

RecommenderではSecurity Command Centerで検知できない放置されたリソースを検知する仕組みを作ることができます。 運用としてはシンプルで、Cloud Asset Inventoryという組織のアセットを一括で取得できるサービスを利用します。

Cloud Schedulerで定期的にCloud Functionを呼び出しCloud Asset Inventoryで組織の中のCompute Engineについて問い合わせ、それらにRecommenderがないかを問い合わせるという仕組みです。

利用例としては

• 利用頻度が低いGoogle Cloudのプロジェクト
• アイドル状態のCompute Engine
• アイドル状態のCloud SQL

などのセキュリティーホールリスクになりえる放置されたリソースを検知することが可能です。

一番上の「利用頻度が低いGoogle Cloudのプロジェクト」を検知することというのは最初の質問の

• 利用頻度の低いGoogle Cloudプロジェクトや利用頻度の低いCompute Engineを検知できるか？

に対する回答になっています。

Workload Identity

Workload Identutyはサービスアカウントキーを使わずに外部プロバイダ（AWS等）からGoogle Cloudへのアクセスを可能とする認証です。

認証用の設定ファイルは必要なのですが、その中にアカウントキーのような情報はないのでサービスアカウントキーが不要になります。 この仕組みを使うと、一部のサービスアカウントキーをなくすことができます。
一つ注意点としてWorkload Identutyではbqコマンドやgsutilコマンドは使えないというものがあります。これについての解決法は本セッションにて紹介されているので、気になる方はぜひ本セッションをご視聴ください。

セッションを視聴して

本セッションは、SCCのStandard＋他のツールで実現するセキュリティ対策という着眼点が面白いなと思ったのでレポートとして書いてみました。 このサービスを使えばセキュリティ対策はばっちりというサービスがあれば嬉しいですが、本セッションのように色々なツールと組み合わせることでより効果を発揮するようなモノも個人的には考え方が面白くて好きでしたし、勉強になりました。

「Google Cloud Day: Digital ’22」では他にも多くのセッションが用意されているのでGoogle Cloudをお使いの方やこれから使いたいと考えている方はぜひ視聴してみてください！